Cs 4120 Lecture 37 Memory Management

ly, we can think of a garbage collector as a thread or threads running perhaps concurrently with the actual compute thread(s). This is shown in Figure 3. We refer to the threads doing real computations as the mutator, since they are changing the object graph that the garbage collector is trying to manage. 3 Reference counting A standard (and often incorrectly implemented) approach to automatic memory management is reference counting. This is a simple local technique for collecting garbage. It is usually avoided because of its high runtime overhead. Each object has a reference count approximating the number of incoming pointers to the object. For example, in Figure 3, the leftmost gray object has no incoming pointers and a reference count of zero. The other two objects have a reference count of one each. This points out the big problem with reference counting: it does not deal with cycles in the object graph, and must be combined with another garbage collection method if cycles are to be reclaimed. When a new reference is created to an object, its reference count is incremented; when a reference is destroyed, its reference count is correspondingly decremented. This means that a simple assignment like x=y requires incrementing the reference count of y and decrementing the reference count of the object x used to point to.1 This is a lot of overhead on top of what was formerly a simple mov between two registers. When the reference count of an object goes to zero, it is ready to be reclaimed. It is tempting to release its memory immediately and decrement the reference counts for all outgoing pointers, but this leads to long pause times. The correct implementation is to push such objects onto a queue, to be processed later. On an allocation request for n bytes, objects totaling n bytes in size should be popped from the queue (if possible) and reclaimed after the reference counts for all successor objects have been decremented appropriately. This deferred decrementing means that the amount of work done by the reference counting machinery at any given moment is relatively small. Popping at least as many bytes from the queue as are requested ensures that the queue doesn’t build up, trapping memory. Reference counting generates a lot of write traffic to memory and hurts performance. This can be reduced by avoiding updating reference counts. The key to this optimization is to notice that it is not necessary that the reference count exactly match the number of incoming references at all times. It is enough to enforce a weaker invariant: • For safety, the reference count should only be decremented to zero if there are no incoming references. • For precision, an object with no incoming references should eventually have a reference count of zero. This weaker invariant implies that it is not necessary to update the reference count to an object over some scope during which an additional reference is known to exist, if it is known that another reference to the object exists and will prevent its count from going to zero. Also, it is possible to defer decrementing the reference count of an object, perhaps until the time of a later increment, in which case both updates can be eliminated. And multiple increments and decrements to the same object can be consolidated. These are all helpful optimizations when generating code that uses reference counting. Researchers have reported reducing reference counting overhead by roughly 80% through such optimizations. 1Note that doing the decrement first could be a disaster if x and y happen to be aliases already!